A storage system is a computer that provides storage service relating to the organization of information on writable persistent storage devices, such as memories, tapes or disks. The storage system may be deployed within a storage area network (SAN) and configured to operate according to a client/server model of information delivery to thereby allow many client systems (clients) to access the information stored on the storage system. Each client may comprise an application executing on a computer that “connects” to the storage system over a computer network, such as a point-to-point link, shared local area network, wide area network or virtual private network implemented over a public network, such as the Internet.
The clients generally utilize block-based access protocols, such as the Small Computer Systems Interface (SCSI) protocol, when accessing information over a SAN-based network. SCSI is a peripheral input/output (I/O) interface with a standard, device independent protocol that allows different peripheral devices, such as disks, to attach to a storage system. In SCSI terminology, clients operating in a SAN environment are “initiator” nodes that initiate commands and requests to access data. The storage system is thus a “target” node configured to respond to the data access requests issued by the initiators in accordance with a request/response protocol. In such a SAN deployment, the client requests (and storage system responses) address the information in terms of block addressing on disk using, e.g., a logical unit number (lun).
A SAN is a high-speed network that enables establishment of direct connections between the storage system and its storage devices. The SAN may thus be viewed as an extension to a storage bus and, as such, an operating system of the storage system enables access to stored data using block-based access protocols over the “extended bus”. In this context, the extended bus may be embodied as Ethernet media adapted to operate with additional block access protocols, such as the SCSI protocol encapsulation over the Transmission Control Protocol/Internet Protocol (TCP/IP), hereinafter referred to as the iSCSI protocol. The iSCSI protocol is well-known and described in detail in J. Satran et al., Request For Comment (RFC) 3720, titled, Internet Small Computer Systems Interface (iSCSI), April 2004, which is hereby incorporated by reference as though fully set forth herein.
Broadly stated, the iSCSI protocol is embodied as iSCSI requests and responses that enable communication between initiator and target nodes over one or more TCP connections. The iSCSI protocol is typically implemented by an iSCSI layer of a protocol stack on each node. The network protocol stack comprises layers of software, such as a transport layer and a network layer. The IP protocol is a network layer protocol that provides network addressing between the nodes, whereas the transport layer provides a port service that identifies processes executing on the nodes and creates a connection between those processes that indicate a willingness to communicate. Examples of conventional transport layer protocols include the TCP protocol.
The connection provided by the transport layer, such as TCP, is a reliable, securable logical circuit between pairs of processes. A TCP process executing on each node establishes the TCP connection in accordance with a conventional “3-way handshake” arrangement involving the exchange of TCP message or segment data structures. The resulting TCP connection is identified by TCP port numbers and IP addresses of the nodes. The TCP protocol and establishment of a TCP connection are described in Computer Networks, 3rd Edition, particularly at pgs. 521-542, which is hereby incorporated by reference as though fully set forth herein. Once established, each TCP connection is configured to carry control messages, SCSI commands, and data within iSCSI protocol data units (PDUs). An iSCSI process of the iSCSI layer builds/receives the iSCSI PDUs and relays/receives them to/from one or more established TCP connections; the group of TCP connections that link an initiator with a target form an iSCSI session.
Each iSCSI node, e.g., initiator or target, has an iSCSI name. The initiator presents its iSCSI initiator name and the iSCSI target name to which it wishes to connect in an initial Login request to establish a new iSCSI session or connection. However, when performing iSCSI discovery, the iSCSI initiator name is required, but the iSCSI target name may be omitted, primarily because iSCSI discovery is often used for target discovery. Typically, the target accepts a specific discovery request (PDU) issued by the initiator that requests relevant information about the target. In response, the target returns all path information (e.g., iSCSI target name and IP address-TCP port pairs) for specific targets, e.g., storage, which the initiator is authorized to access.
A network environment may be provided wherein information (data) is stored in secure storage served by one or more storage systems coupled to one or more security appliances. Each security appliance is embodied as a standalone computer that is inserted between each client and storage system, and that intercepts data access requests and responses exchanged between the client and storage system over the network. Specifically, the security appliance is configured to transform unencrypted data (cleartext) generated by clients (or initiators) into encrypted data (ciphertext) destined for secure storage or “cryptainers” on the storage system (or target). As used herein, a cryptainer is a logical construct comprising physical storage on a storage device, such as a disk, in which the encrypted data is stored. In the context of a SAN environment, a cryptainer can be, e.g., a disk, a region on the disk or several regions on one or more disks that, in the context of a SAN protocol such as iSCSI, is accessible as a lun.
Each cryptainer is associated with its own encryption key, e.g., a cryptainer key, which is used by the security appliance to encrypt and decrypt the data stored on the cryptainer. An encryption key is a code or number which, when taken together with an encryption algorithm, defines a unique transformation used to encrypt or decrypt data. Data remains encrypted while stored in a cryptainer until requested by an authorized client. At that time, the security appliance retrieves the encrypted data from the cryptainer, decrypts it and forwards the unencrypted data to the client.
In the network environment described above, each client and storage system may have one or more iSCSI names, wherein the iSCSI names of the storage system may be associated with, e.g., different cryptainers served by the storage system. Therefore, communication between the client and storage system involves management of a plurality of iSCSI names. Since it is embodied as a standalone computer between the client and storage system, the security appliance may be required to manage additional iSCSI names. This is primarily because the storage system “views” the security appliance as a new client, whereas the client views the security appliance as a new storage system (or new storage device). Consequently, insertion of the security appliance between the client and storage system without further iSCSI name mapping/configuration may render the environment inoperable.
A conventional solution to this problem is to configure the security appliance with a new iSCSI initiator name so that the storage system can recognize the security appliance. In addition, the security appliance is configured with one or more new iSCSI target names so that the client can recognize the security appliance. However this is a complicated and costly solution that requires management of a large number of iSCSI names at the security appliance.